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I. STATUS OF CLAIMS 

A. Total Number of Claims in Application 
There are 1 9 claims pending in the application. 

B. Current Status of Claims 

1. Claims canceled: 6, 15, and 19 

2. Claims withdrawn from consideration but not canceled: None 

3. Claims pending: 1-5, 7-14, 16-18 and 20-22 

4. Claims allowed: None 

5. Claims rejected: 1-5, 7-14, 16-18 and 20-22 

C. Claims On Appeal 

The claims on appeal are claims 1-5, 7-14, 16-18 and 20-22 
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II. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The grounds of rejection to be reviewed are the same as in Appellant's Appeal Brief: 

Claims 1-5, 8-13, 16-18, and 20-22 are rejected under 35 U.S.C. §103(a) as being 
unpatentable over US Patent 6,182,249 (hereinafter, Wookey), 

Claims 7 and 14 are rejected imder 35 U.S.C. §103(a) as being unpatentable over 
Wookey in view of Transact-SQL User's Guide, 1996 (hereinafter, Sybase), 

III. ARGUMENT 

A. Note on "Grouping of Claims" 

On page 3 of the Examiner's Answer, the Examiner remarks that all of the claims 
should stand or fall together because Appellant's Appeal Brief did not include a statement 
under 37 C.F.R. §1 .192(c)(7). Appellant notes that the claims should not stand or fall 
together, as the Examiner's understanding is based upon a rule that has been replaced. 
Specifically, such requirement set forth in 37 C.F.R. § 1.192(c)(7) has been replaced by 
requirements in 37 C.F.R. §41.37(c)(l)(vii). The new rule replaces the old requirement for 
the "stand or fall together" statement with a new requirement for separate subheadings and 
separate arguments for claims to be separately considered. Appellant respectfully submits 
that the Appeal Brief complies with the requirements of 37 C.F.R. §41.37(c)(l)(vii) and that 
claims argued separately therein should be separately considered. 

B. Note on "Claims Appealed" 

On page 3 of the Answer, the Examiner notes that the Appendix supplied with the 
Appeal Brief failed to list claims 16-18 and 20-22, which are on appeal. Appellant 
apologizes for the confiision and thanks the Examiner for his consideration in supplying a 
listing of the claims. The claims supplied by the Examiner properly reflect the claims as they 
now stand with mark-ups showing amendments entered prior to appeal. 



25601594.1 



3 



Application No.: 09/422,998 



Docket No.: 10990763-2 



C. First Ground of Rejection 

Appellant hereby reiterates the arguments presented in the Appeal Brief by reference 
thereto, and submits the further arguments below to address the specific points raised in the 
Examiner's Answer. The claims stand or fall according to the organization in the Appeal 
Brief as specified by 37 C.F.R. §41.37(c)(l)(vii); however, some of the arguments presented 
below addressing specific points in the Examiner's Answer are not argued for each claim 
under separate headings, but are instead combined for one or more claims in order to provide 
brevity for the convenience of the Board. Appellant maintains that the claims argued 
separately in the Appeal Brief should be considered separately, even if not addressed 
separately herein. 

Claims 1-5, 8-13, 16-18, and 20-22 are rejected under 35 U.S.C. §103(a) over 
Wookey, Appellant traverses the rejection of claims 1-5, 8-13, 16-18, and 20-22 by showing 
lack of proper motivation to modify Wookey and failure to show claimed limitations in 
Woo key as modified. 

1 . Lack of Motivation to Modify 

The proposed modifications of Wookey are improper because the motivation provided 
by the Examiner is incorrect. In rejecting claims 1, 4, 13, and 18, the Examiner provides the 
following reasoning: 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to use the diagnostic test as query for existence 
of attribute condition in order to issue an alert indicating predefined condition 
exist in a computer system. 

See, e.g., Final Action at 15. This is the reasoning used throughout the Final Action to reject 
claims 1-5, 8-13, 16-18, and 20-22. As explained in the Appeal Brief, such motivation is 
incorrect because the system of Wookey, without modification, issues an alert indicating a 
predefined condition exists in a computer system. See Wookey at Abstract, first sentence. 
Accordingly, one of ordinary skill in the art would not be motivated to modify Wookey, as 
proposed. 

In the Examiner's Answer, the Examiner does not cure the deficiency nor adequately 
explain the motivation supplied in the Final Action. Note, for instance, the Examiner's 
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argument at pages 23-25 of the Examiner's Answer. Such argument is repeated at pages 29- 
30, 37-38, and 42-44 of the Examiner's Answer. In the arguments, the Examiner appears to 
describe various features of the JVookey system, specifically emphasizing enablement and 
disablement of tests according to the monitored system. Without conceding that the 
Examiner's assertions in the arguments correctly characterize Wookey, it is asserted that the 
arguments are irrelevant to the issue of motivation to modify. For instance, the arguments do 
not address the fact that Wookey, without modification, issues an alert indicating a predefined 
condition exists in a computer system. Further, the arguments do not clarify the original 
statement regarding motivation, nor do they provide another reason why one of ordinary skill 
in the art would have been motivated to modify JVookey. Thus, the rejection fails to provide 
proper motivation for the modification. 

A further instance of lack of motivation to modify JVookey exists in the rejections. In 
the "Response to Arguments" portion of the Examiner's Answer, the Examiner states: 

As suggested by JVookey, the test can be selectively enabled or 
disabled according to the monitored system (Col. 16, lines 19-20). Because, 
as it was well known to one of ordinary skill in the art, in order to enable a 
specific test, a test name has to be specified, e.g., dt test, by selecting as taught 
by JVookey, and the test or query is specified by the enable request via test 
name. 

Examiner's Answer at 24 (emphasis omitted). It appears from this paragraph that the 
Examiner is suggesting that specifying a particular test by name is not taught or suggested by 
JVookey but is known in the art. However, the Examiner has not provided any reason why 
one of skill in the art would be motivated to modify JVookey to provide for specifying a 
particular test by name. Thus, the rejection fails to provide proper motivation for the 
modification, and no prima facie case of obviousness is made. Accordingly, the rejection of 
claims 1-5, 8-13, 16-18, and 20-22 should be overtumed. 

2. Failure to Teach or Suggest Every Limitation 

a. Claims 1, 4, 13, and 18 

In addition to the lack of motivation, the 35 U.S.C. §103 rejection is improper because 
JVookey does not teach or suggest every element of claims 1,4, 13, and 18. JVookey teaches 
two computer systems — a monitoring system (system 100 of figure la) and a monitored 
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system (system 102 of figure lb). The monitored system runs diagnostic tests on itself and 
periodically reports the results to the monitoring system. See Wookey at Col. 3, line 3 
through Col. 4, line 1 1 . The tests that are performed are run under the control of monitor 
control software that is contained within the monitored system. See Id. at Col. 4, lines 4-6 
and figures la and lb. When the monitoring system receives the results of the diagnostic 
tests, it creates a model of the state of the monitored system and compares that model to one 
or more alarms that are set to indicate predefined conditions. Id. at Abstract. Output to the 
user is in the form of token values, host states, or alarms. See Id, at Col. 11, lines 8-44, and 
Col. 1 6, lines 41-42. Wookey does not teach or suggest that the results of tests are viewable 
by a user. 

In the Examiner's Answer, the Examiner changed the reasoning for the rejections 
used in the Final Action in response to the Appeal Brief Specifically, the Examiner points to 
the support engineer to teach a client (in the case of claims 1, 4, and 13) and to a Graphical 
User Interface (GUI) to teach a client application program (in the case of claim 1 8), See 
Examiner's Answer at 5, 9, 14, and 17. Also, the Examiner argues that the tests must be 
selectively enabled by the support engineer or GUI, thereby teaching a request that is a query 
from a client or client application program. See Id,, e.g., at 7-8. However, the argument still 
fails to show that the claims are obvious over Wookey^ as discussed below. 

First, contrary to the Examiner's assertion, a test in Wookey is not "a request from a 
client to notify said client of a condition of an attribute of a system," (emphasis added) as 
recited by claims 1, 4, and 13, nor is it "a request to notify said client application program of 
a condition of an attribute of a system," (emphasis added) as recited by claim 18. As 
mentioned above, Wookey does not teach or suggest that a support engineer or GUI sees the 
results of the tests; rather, output is in the form of alerts, token values, or host states. See 
Wookey at Col. 11, lines 8-44, and Col. 16, lines 41-42. Thus, the tests themselves are not 
requests "from a client to notify said client of a condition of an attribute of a system" or 
requests "to notify said client application program of a condition of an attribute of a system." 
Accordingly, the Examiner's new reading of Wookey fails to teach or suggest "a request from 
a client to notify said client of a condition of an attribute of a system," as recited by claims 1, 
4, and 13 and "a request to notify said client application program of a condition of an 
attribute of a system," as recited by claim 18. 
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Additionally, the Examiner's reasoning that Wookey teaches or suggests, "using by 
said reporting application said query for querying said system as specified by said request, for 
existence of said condition of said attribute," as recited by claim 1, is incomplete. Similarly 
the reasoning is likewise incomplete in the Examiner's assertion that Wookey teaches "using 
said query for querying said systems as specified by said request, for existence of said 
condition of said attribute," as recited by claim 4, or "querying said system as specified by 
said request," as recited by claims 13 and 18. For example, Wookey does not teach or suggest 
that the tests can be selectively enabled by a support engineer, as alleged by the Examiner. 
The Examiner states: 

As suggested by Wookey, the test can be selectively enabled or 
disabled (Col. 16, Lines 19-20). Obviously, in the knowledge of one of 
ordinary skill in the art, to receive an alert of a particular system attribute, e.g., 
alert indicates the amount of disk free is below a threshold, a support engineer 
has to make a request of a specific test to be enabled, e.g., dt test, by selecting 
as taught by Wookey, and the test or query is specified by the enable request. 

Examiner's Answer at 7-8 (emphasis omitted). However, the Examiner incorrectly assumes 
that Wookey teaches that the support engineer can enable or disable tests. Wookey merely 
states at column 16, lines 19-20 that the tests can be selectively enabled or disabled 
"according to the monitored system." In fact, it appears that this is the only sentence in 
Wookey that mentions such enabling and disabling. Wookey does not teach or suggest that a 
support engineer can perform the enabling and disabling because merely mentioning enabling 
and disabling is not enough, without more, to teach or suggest who or what performs the 
enabling and disabling. 

The further shortcoming in the Examiner's reasoning is evident from the above- 
quoted passage from the Examiner's Answer, wherein the Examiner states that "a support 
engineer has to make a request of a specific test to be enabled," (emphasis added). Once 
again, the Examiner reads too much into Wookey, as Wookey does not teach or suggest that a 
support engineer must enable specific tests. That specific tests may be enabled or disabled is 
not enough, without more, to teach that a support engineer must enable tests. 

Thus, Wookey does not teach or suggest that a support engineer may or must enable or 
disable tests in the Wookey system. Accordingly, the new reasoning fails to support the 
rejections. Should the Examiner intend to now argue that selectively enabling and disabling 
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is a known feature that may be combined with Wookey, such an assertion constitutes a new 
ground of rejection that must specify the requisite motivation for making such combination. 

As shown above, the new reading of Wookey in the Examiner's Answer still fails to 
show that Wookey teaches or suggests, "using by said reporting application said query for 
querying said system as specified by said request, for existence of said condition of said 
attribute," as recited by claim 1, "using said query for querying said systems as specified by 
said request, for existence of said condition of said attribute," as recited by claim 4, or 
"querying said system as specified by said request," as recited by claims 13 and 18. Further, 
the new reading also fails to show that Wookey teaches or suggests, "a request from a client to 
notify said client of a condition of an attribute of a system," as recited by claims 1, 4, and 13, 
nor is it "a request to notify said client application program of a condition of an attribute of a 
system," as recited by claim 18. Accordingly, reversal of the rejection of claims 1,4, 13, and 
1 8 is respectfully requested. 

b. Dependent Claims 

Dependent claims 2, 3, 5, 8-12, 16, 17, and 20-22 are allowable over the rejection of 
record at least because they depend from respective dependent claims 1,13, and 18. 
Additionally, the claims recite features that are patentable in their own right, as discussed 
further in Appellant's Appeal Brief. 

i. Claim 8 

In the Appeal Brief, Appellant argued that Wookey does not teach or suggest at least 
"wherein said information specifying a query for said system attribute comprises multiple 
transactions bracketed together," as recited in part by claim 8. In response to the Appeal 
Brief, the Examiner changed the reasoning for the rejection of claim 8 from that provided in 
the Final Office Action, stating: 

As disclosed by Wookey, the tests can be selectively enabled or disable 
according to the monitor system (Col. 16, Lines 19-20). Wookey further 
discloses the tests are run at a particular time period (Col. 5, Lines 45-46). As 
seen, in order to specify a test or query in an enable request, a support engineer 
have to select a test for enabling, also specify a run time for the test. Selecting a 
test for enabling, and specifying a run time are multiple transactions bracketed 
together. 
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Examiner's Answer at 1 1 and 34. In other words, the Examiner now asserts that enabling a 
test and specifying a time period for the test are bracketed transactions. However, Wookey 
does not teach or suggest that an engineer can specify a time period for tests to run. Wookey 
merely states that "a host state is the state of the monitored system . . . over the particular time 
period that the diagnostic tests were run." Wookey at Col. 5, lines 44-46. Furthermore, 
Wookey certainly does not teach or suggest that an engineer must specify a run time for the 
test, as asserted by the Examiner. See Examiner's Answer at 1 1 and 34. Accordingly, it is 
respectfully requested that the 35 U.S.C. §103 rejection of claim 8 be overturned. 

ii. Claim 9 

In the Appeal Brief, Appellant argued that Wookey does not teach or suggest at least 
"multiple conditions bracketed together, wherein upon determining that such bracketed 
conditions exist, notifying said client of the existence of such bracketed conditions," as 
recited by claim 9. In response to Appeal Brief, the Examiner changed the reasoning in the 
rejection of claim 9, and now points to passages at column 12 of Wookey as teaching the 
above-recited feature. However, such passages merely discuss alerts, which, as explained 
below, fail to teach or suggest the subject matter recited by claim 9 and its base claim, claim 
1. 

According to claim 9, "said condition comprises: multiple conditions bracketed 
together." The condition referred to is introduced in claim 1 , which recites, "receiving by a 
reporting application ... a request from a client to notify a client of a condition of an attribute 
of a system." Thus, the "condition" is the object of the recited "request," according to claims 
1 and 9. However, in rejecting claim 1 the Examiner relies on the tests of Wookey, rather 
than the alerts, to teach a request. See Examiner's Answer at page 5, last paragraph, where 
the Examiner equates the enablement/disablement of tests by an engineer with requests. The 
Examiner relies on tests rather than on alerts to teach requests because the alerts of Wookey 
are not taught to affect the information retxmied from the tests that are run on the monitored 
system, whereas claim 1 recites that the request comprises information specifying a query for 
a system attribute, and a query is used by the reporting application to query the system. Thus, 
the rejections of claims 1 and 9 cannot be supported by citing Wookey' s alerts as teaching 
requests. The alerts of Wookey do not teach or suggest requests, and as a result, the 
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conditions cited by the Examiner do not teach or suggest the multiple conditions bracketed 
together in claim 9. 

Thus, as shown above, when the language of claim 9 is read in context with its base 
claim, the cited alerts do not teach or suggest the claimed multiple conditions bracketed 
together. Accordingly, it is respectfully requested that the 35 U.S.C. §103 rejection of claim 
9 be overturned. 

iii. Claim 10 

In the Appeal Brief, Appellant argued that Wookey does not teach or suggest at least, 
"multiple changes bracketed together, wherein upon determining that such bracketed changes 
exist, notifying said client of the existence of such bracketed changes," as recited by claim 10 
In response to Appeal Brief, the Examiner changed the reasoning in the rejection of claim 10 
from that provided in the Final Office Action. The Examiner's Answer states: 

As disclosed by Wookey, a predictive alert analyzes historical and current data to 
identify trends (Col. 12, Lines 14-15), e.g., detecting increasing disk usage and 
predict the problem before the threshold of 99 % is reached (Col. 12, Lines 27- 
43). As seen, a current change in disk usage, and a historical change are 
bracketed for comparing to raise an alert before the threshold of 99 % is 
reached 

Examiner's Answer at 12 and 36-37. In other words, the Examiner now points to passages at 
column 12 of Wookey to teach the above-recited feature; however, such passages fail to teach 
or suggest the feature because the passages discuss alerts, which, as explained below, fail to 
teach or suggest the subject matter recited by claim 10 and its base claims, claims 1 and 9. 

Claim 10 depends from claim 9, and it specifies that the condition of claim 9 
comprises multiple changes bracketed together. As explained above with regard to claim 9, 
the alerts of Wookey do not teach or suggest the claimed condition. As a result, the alerts of 
Wookey also do not teach or suggest the "multiple changes bracketed together" of claim 10. 
Thus, as shown above, when the language of claim 10 is read in context with its base claims, 
the cited alerts do not teach or suggest the claimed multiple changes bracketed together. 
Accordingly, it is respectfully requested that the 35 U.S.C. §103 rejection of claim 10 be 
overturned. 
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iv. Claim 17 

In the Appeal Brief, Appellant argued that Wookey does not teach or suggest 
"multiple changes bracketed together," as recited in part by claim 17. In response to Appeal 
Brief, the Examiner changed the reasoning in the rejection of claim 17 from that provided in 
the Final Office Action. The Examiner's Answer states: 

As disclosed by Wookey^ a predictive alert analyzes historical and current data to 
identify trends (Col. 12, Lines 14-15), e.g., detecting increasing disk usage and 
predict the problem before the threshold of 99 % is reached (Col. 12, Lines 27- 
43). As seen, a current change in disk usage, and a historical change are 
bracketed for comparing to raise an alert before the threshold of 99 % is 
reached 

Examiner's Answer at 16 and 42. In other words, the Examiner now points to passages at 
column 12 of Wookey to teach the above-recited feature; however, such passages fail to teach 
or suggest the feature because the passages discuss alerts, which fail to teach or suggest the 
subject matter recited by claim 17 and its base claim, claim 13. The alerts of Wookey do not 
teach or suggest the multiple changes bracketed together of claim 17 for the same reasons 
that the alerts of Wookey do not teach or suggest the subject matter of claims 9 and 10. That 
is, when the language of claim 17 is read in context with the language of its base claim, claim 
13, it is apparent that the alerts do not teach or suggest the claimed changes. Accordingly, it 
is respectfully requested that the 35 U.S.C. §103 rejection of claim 17 be overturned. 

D. Second Ground of Rejection 

Appellant hereby reiterates the arguments presented in the Appeal Brief by reference 
thereto, and submits the fxirther arguments below to address the specific points raised in the 
Examiner's Answer. The claims stand or fall according to the organization in the Appeal 
Brief as specified by 37 C.F.R. §41.37(c)(l)(vii); however, some of the arguments presented 
below are not argued for each claim under separate headings. Rather, various arguments may 
be combined for one or more claims in order to provide brevity for the convenience of the 
Board. Appellant maintains that the claims argued separately in the Appeal Brief should be 
considered separately, even if not addressed separately herein. 

Claims 7 and 14 are rejected under 35 U.S.C. § 103(a) over Wookey in view of Sybase, 
Appellant traverses the rejection of claims 7 and 14 by showing lack of proper motivation to 
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combine Wookey and Sybase and failure to show claimed limitations in the combination of 
Woo key and Sybase. 

1 . Lack of Motivation to Modify 

The proposed modifications of Wookey are improper because the motivation provided 
by the Examiner is incorrect. In rejecting claims 7 and 14, the Examiner provides the 
following reasoning: 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to use the diagnostic test for querying the system 
and using SQL as taught by Sybase to implement the test in order to issue an 
alert indicating predefined condition exist in a computer system. 

See Final Action at 26. As explained in the Appeal Brief, such a motivation is incorrect 
because the system of Wookey, without modification or combination, already issues an alert 
indicating a predefined condition exists in a computer system. See Wookey at Abstract, first 
sentence. Accordingly, one of ordinary skill in the art would not be motivated to combine 
Wookey, as proposed. 

In the Examiner's Answer, the Examiner does not cure the deficiency nor adequately 
explain the motivation supplied in the Final Action. Note, for instance, the response 
argument at pages 47-48 of the Examiner's Answer. In the arguments, the Examiner appears 
to describe various features of the Wookey system, specifically emphasizing enablement and 
disablement of tests according to the monitored system. Without conceding that the 
Examiner's assertions in the arguments correctly characterize Wookey, it is asserted that the 
arguments are irrelevant to the issue of motivation to combine. For instance, the arguments 
do not address the fact that Wookey, without being combined with features from Sybase, 
issues an alert indicating a predefined condition exists in a computer system. Further, the 
arguments do not clarify the original statement regarding motivation, nor do they provide 
another reason why one of ordinary skill in the art would be motivated to combine Wookey 
and Sybase. Thus, the rejection fails to provide proper motivation for the modification. 

An additional instance of lack of motivation to modify Wookey exists in the 
rejections. In the Response to Arguments portion of the Examiner's Answer, the Examiner 
states: 
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As seen, in order to receive an alert of a particular system attribute. . . a support 
engineer at the monitoring computer system 100 has to make a request of a 
specific test to be enabled. . . by selecting, and the enable request is from the 
support engineer as client. In order to enable a test to get the test data. . . the test 
name has to be specified in the enable request, . . . and the test or query is specified 
by the enable request via the test name. 

As supportive evidence for examiner's conclusion, the examiner respectfiiUy 
refers appellants to USP 6,023,507. . . As illustrated in USP 6,023,507, the 
monitoring software on the monitored system includes an administrator tool, 
and communications software (Col. 5, Lines 56-59) for communicating with 
monitoring system (Col. 5, Line 66-Col. 6, Line 2). 

Examiner's Answer at 50 (emphasis omitted). It appears from this paragraph that the 
Examiner is suggesting that specifying a particular test by name is not taught or suggested by 
Wookey but is known in the art. However, the Examiner has not provided any reason why 
one of skill in the art would be motivated to modify Wookey to provide for specifying a 
particular test by name. Thus, the rejection fails to provide proper motivation for the 
modification, and no prima facie case of obviousness is made. Accordingly, the rejection of 
claims 7 and 14 should be overturned. 



2. Failure to Teach or Suggest Every Limitation 
a. Claim 7 

In addition to the lack of motivation, the 35 U.S.C. §103 rejection is improper because 
Wookey does not teach or suggest every element of claim 7. In the Examiner's Answer, the 
Examiner changed the arguments used in the Final Action in response to Appeal Brief 
Specifically, the Examiner points to the support engineer to teach a client. See Examiners 
Answer at 20 and 50. Also, the Examiner argues that the tests must be selectively enabled by 
the support engineer, thereby teaching a request that is a query from a client. See Id., e.g., at 
21-22 and 50. However, the argument still fails to show that the claims are obvious over 
Wookey and Sybase, 

First, contrary to the Examiner's assertion, a test is not "a request from a client to 
notify said client of a condition of an attribute of a system," as recited by claim 7. As 
mentioned above, Wookey does not teach or suggest that a support engineer sees the results of 
the tests; rather, output is in the form of alerts, token values, or host states, not test results. 
See Wookey at Col. 11, lines 8-44, and Col. 16, lines 41-42. Thus, the tests themselves are 
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not requests "from a client to notify said client of a condition of an attribute of a system." 
Accordingly, the Examiner's new reading of Wookey fails to teach or suggest "a request from 
a client to notify said client of a condition of an attribute of a system," as recited by claim 7. 

Additionally, the Examiner's reasoning in reaching the conclusion that Wookey 
teaches or suggests, "querying said system as specified by said request," as recited by claim 
7, is incomplete. For example, JVookey does not teach or suggest that the tests can be 
selectively enabled by a support engineer, as alleged by the Examiner. The Examiner states: 

As seen, in order to receive an alert of a particular system attribute. . . a support 
engineer at the monitoring computer system 100 has to make a request of a 
specific test to be enabled. . . by selecting, and the enable request is from the 
support engineer as client. In order to enable a test to get the test data. . . the test 
name has to be specified in the enable request, . . . and the test or query is specified 
by the enable request via the test name. 

Examiner's Answer at 50 (emphasis omitted). However, the Examiner incorrectly assumes 
that Wookey teaches that the support engineer can enable or disable tests. Wookey merely 
states at column 16, lines 19-20 that the tests can be selectively enabled or disabled 
"according to the monitored system." In fact, it appears that this is the only sentence in 
Wookey that mentions such enabling and disabling. Wookey does not teach or suggest that a 
support engineer can perform the enabling and disabling because merely mentioning enabling 
and disabling is not enough, without more, to teach or suggest who or what performs the 
enabling and disabling. 

The second hole in the Examiner's reasoning is evident from the above-quoted 
passage from the Examiner's Answer, wherein the Examiner states that "a support engineer at 
the monitoring computer system 100 has to make a request of a specific test to be enabled," 
(emphasis added). Once again, the Examiner reads too much into Wookey, as Wookey does 
not teach or suggest that a support engineer must enable specific tests. That specific tests 
may be enabled or disabled is not enough, without more, to teach that a support engineer 
must enable tests. 

Thus, Wookey does not teach or suggest that a support engineer may or must enable or 
disable tests in the Wookey system. Accordingly, the new reasoning fails to support the 
rejections. Should the Examiner argue that selectively enabling and disabling is a knovm 
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feature that may be combined with Wookey, such an assertion is proper only in a new ground 
of rejection with the requisite motivation. 

As shown above, the new reading of Wookey in the Examiner's Answer still fails to 
show that Wookey teaches or suggests "querying said system as specified by said request," as 
recited by claim 7. Further, the new reading also fails to show that Wookey teaches or 
suggests, "a request from a client to notify said client of a condition of an attribute of a 
system," as recited by claim 7. Accordingly, reversal of the rejection of claim 7 is 
respectfully requested. 

b. Claim 14 

It is respectfully submitted that dependent claim 14 is allowable at least because of its 
dependence from claim 13 for the reasons discussed above. Accordingly, Appellant 
respectfully requests that the rejection of claim 14 be reversed. 
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